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1  Scope 

1.1  Purpose 

The  Robotics  Systems  Joint  Project  Office  (RS  JPO)  has  launched  an  initiative  to 
identify  and  define  interoperability  standards  to  be  organized  and  maintained  within  an 
Unmanned  Ground  Vehicle  (UGV)  Interoperability  Profile  (IOP).  This  IOP  will  be 
employed  by  UGV  acquisition  managers  in  the  acquisition  of  future  Programs  of 
Record,  the  upgrade  of  fielded  systems,  and  the  evaluation/acquisition  of  Commercial- 
Off-The-Shelf  (COTS)  products. 

A  primary  goal  of  this  initiative  is  to  leverage  existing  and  emerging  standards  within  the 
Unmanned  Vehicle  (UxV)  community  such  as  the  Society  of  Automotive  Engineers 
(SAE)  AS-4  Joint  Architecture  for  Unmanned  Systems  (JAUS)  standard,  the  Advanced 
Explosive  Ordnance  Disposal  Robotic  System  (AEODRS)  Architecture  Description 
Documents  Version  1.0,  and  the  Army  Unmanned  Aircraft  Systems  (UAS)  Project  Office 
lOPs  with  an  end  goal  of: 

-  Facilitating  interoperability  among  new  UGV  initiatives  and  legacy  systems; 

-  Facilitating  interoperability  between  controllers  and  UxV  robotic  system(s); 

-  Facilitating  collaboration  between  UGV  and  UAS  systems; 

-  Providing  a  path  forward  to  standardized  interoperable  technology  solutions 

-  Promoting  payload  and  on-board  subsystem  modularity  and  commonality  across 
the  portfolio  of  UGV  systems. 

IOP  Version  0  (VO)  has  been  developed  using  a  government/industry  Working 
Integrated  Product  Team  (WIPT)  structure,  and  defines  the  interoperable  interfaces  and 
protocols  necessary  to  enable  interoperability  and  modularity  to  be  introduced  to  the 
capabilities  that  have  already  been  widely  fielded.  The  exact  set  of  capabilities 
addressed  in  IOP  VO  is  described  in  the  UGV  IOP  VO  Capabilities  Plan.  The  RS  JPO 
intends  to  publish  annual  revisions  to  the  IOP  in  order  to  expand  and  evolve  its  scope 
as  necessary,  based  on  the  evolution  of  Warfighter  capability  requirements  and 
technological  advances. 

1.2  Document  Structure  &  Overview 

This  document  provides  the  base  concepts,  architecture,  requirements,  and  overview 
for  the  UGV  IOP;  and  specifically  addresses  platform,  payload,  mobility,  on-vehicle 
network,  communication,  and  messaging  requirements.  Additionally,  this  document 
introduces  and  presents  the  conformance  and  validation  approach  to  be  employed 
within  the  IOP.  The  complete  set  of  documents  that  comprise  the  UGV  IOP  and  their 
intended  usage  is  presented  below. 
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UGV  IOP  -  Overarching  Profile 

In  addition  to  the  topics  specified  above,  this  document  also  provides  three  separately 
published  attachments  that  comprise  the  Overarching  IOP  VO.  These  attachments  are 
described  below: 

-  UGV  IOP  VO  -  Capabilities  Plan 

Defines  capability  requirements  related  to  the  employment  and  usage  of  UGVs  to 
perform  current  and  relevant  near-term  robotic  missions,  in  turn  scoping  and 
bounding  the  content  of  the  UGV  IOP.  This  Capabilities  Plan  is  based  on  a 
mission  analysis  that  reviewed  the  usage  of  currently  fielded  UGVs  and  the 
capability  requirements  of  a  number  of  existing  and  emerging  Programs  of 
Record. 

-  UGV  IOP  -  SAE  JAUS  Profiling  Rules 

Specifies  the  manner  in  which  the  SAE  AS-4  JAUS  standards  have  been 
profiled,  to  include  clarification  or  additional  content  to  define  interoperability 
between  controllers  and  UGVs  as  well  as  intra-UGV  (platform/subsystem) 
interoperability. 
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-  UGV IOP  -  Custom  Services,  Messages  and  Transports 

Specifies  additional  SAE  AS-4  JAUS  messages  and  transport  protocols  required 
to  support  the  scope  of  the  UGV  IOP.  Although  titled  “custom”,  these  messages 
are  published  and  standardized  within  the  UGV  IOP  community  with  the  end  goal 
of  transitioning  to  the  SAE  AS-4  JAUS  standard(s)  for  official  adoption. 

UGV  IOP  -  Control  Profile 

This  document  specifies  the  Operator  Control  Unit  (OCU)  logical  architecture, 
standards,  Human-Machine  Interface  (HMI)  requirements,  and  conformance  approach 
to  include  host  application  user  interface  requirements,  such  as  mission  planning  and 
command  and  control.  Although  OCU  concepts  and  high  level  architecture  are  touched 
upon  in  the  Overarching  Profile,  the  Control  Profile  provides  the  more  detailed 
requirements  to  specify  how  interoperability  is  to  be  achieved  for  conformant  controllers. 

UGV  IOP  -  Payloads  Profile 

This  document  specifies  the  payload  classification,  standards,  requirements,  and 
conformance  approach.  Although  these  concepts  are  touched  upon  in  the  Overarching 
Profile,  the  Payloads  Profile  provides  the  more  detailed  requirements  to  specify  the 
interoperability  requirements  for  payloads  with  respect  to  the  UGV  platform. 

UGV  IOP  -  Communications  Profile 

This  document  specifies  the  communications  standards,  requirements,  and 
conformance  approach.  Although  these  concepts  are  touched  upon  in  the  Overarching 
Profile,  the  Communications  Profile  provides  the  more  detailed  requirements  to  specify 
interoperability  requirements  for  communications  between  and  among  controllers  and 
UGVs. 

1.3  Discussion  of  Technical  Topics 
1.3.1  Interoperability  Attributes 

The  UGV  IOP  has  been  designed  to  support  interoperability  on  a  variety  of  missions 
and  objectives,  vehicle  classes/types,  controller  classes/types,  payload  classes/types, 
physical/software  architectures,  and  interaction  with  external  systems  (e.g.,  networks, 
C2).  Since  every  interoperability  requirement  will  not  be  applicable  to  every  system,  the 
IOP  provides  a  mechanism  to  independently  specify  these  requirements  in  a 
composable  manner,  using  Interoperability  Attributes.  In  this  way,  Interoperability 
Attributes  applicable  to  the  specification  and  design  of  a  system  can  be  identified  and 
subsequently  utilized  to  filter  applicable  requirements  from  the  UGV  IOP,  supporting 
system  design,  development,  conformance  and  validation  testing,  initial  operational  test 
and  evaluation,  and  fielding. 
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Throughout  the  UGV  IOP,  the  term  “Interoperability  Attributes”  has  been  designated  to 
identify  these  composable  attributes,  which  may  be  specified  as  options  in  the 
application  of  the  UGV  IOP  to  a  system  acquisition  activity.  This  concept  is  depicted 
below  in  Figure  1-1 . 


Interoperability  Attribute 

Selectable  Values 

Associated  Requirements 

Transport 

JUDP 

Robotic  systems  (controllers  and/or  vehicles) 
with  a  designated  "JUDP"  transport 
Interoperability  Attribute  shall  implement  the 
transport  in  compliance  with  the  JUDP 
transport  specified  in  SAE  JAUS  AS5669A. 

JTCP 

Robotic  systems  (controllers  and/or  vehicles) 
with  a  designated  "JTCP"  transport 
Interoperability  Attribute  shall  implement  the 
transport  in  compliance  with  the  JTCP 
transport  specified  in  SAE  JAUS  AS5669A. 

Custom 

Robotic  systems  (controllers  and/or  vehicles) 
with  a  designated  "Custom"  transport 
Interoperability  Attribute  shall  implement  the 
transport  in  compliance  with  the  designated 
Custom  transport  specified  in  UGV  IOP 

Custom  Service  Messages  and  Transports. 

Figure  1-1  Interoperability  Attribute  Concept  Example 


System  requirements  specified  in  the  UGV  IOP  are  tagged,  accordingly,  with 
Interoperability  Attribute  designations.  The  manner  in  which  the  attribute  is  to  be 
interpreted  is  also  specified  within  the  UGV  IOP.  It  is  acknowledged  that  UGV 
requirements  will  vary  based  upon  capability,  mission,  and  other  acquisition 
requirements.  For  this  reason,  the  capabilities  defined  within  this  IOP  have  been  subset 
via  Interoperability  Attributes  that  specify  the  robotic  system  capabilities  in  a  granular 
fashion,  from  the  most  simple  to  the  most  complex.  The  Interoperability  Attributes  are 
utilized  to  determine  what  capability  is  required  along  with  what  requirements  are 
applicable  to  each  capability  (to  include  test  and  validation).  In  some  cases, 
Interoperability  Attributes  specify  choices  which  may  be  mutually  exclusive,  while  in 
other  cases,  multiple  options  of  the  same  Interoperability  Attribute  may  be  allowable. 

The  figure  also  depicts  a  “conceptual”  interoperability  template  that  can  be  utilized  by 
various  stakeholders  to  include  the  acquisition  developer,  the  prime  system  developer, 
and  the  conformance  and  validation  tester.  The  RS  JPO  has  the  responsibility  for 
identifying  the  Interoperability  Attributes  applicable  to  each  acquisition  program.  The 
prime  systems  developer  has  the  responsibility  for  implementing  the  UGV  IOP  in 
accordance  with  the  specified  Interoperability  Attributes,  and  the  conformance  and 
validation  tester  has  the  responsibility  for  developing  and  executing  conformance  tests, 
based  on  those  Interoperability  Attributes. 
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lOPVx 

Capability  Plan 


Functional  Scope  of  IOP  Vx 


Scopes  what  is  and  what  is  not  being 
addressed  by  lOPs 


Overarching  IOP 


Payload 

IOP 


Control  ■  Communications 

IOP  I  IOP 


-Interface  Requirements 
-Selectable  Interoperability  Attributes 
-Required  Standards  &  Protocols 


tOH  Contotmanc 

?  ana  validation  o laus 

JAUS  Profiling 
Rules 


-Contract  Performance 
Reqs 

-  Selected  Interoperability 
Attributes 


Conformance 
Test  Activity 


-JAUS  Msg  Reqs 
-SA/V  Protocol  Guidance 


Figure  1-2  Mission/UGV  IOP  Flowdown 


As  shown  in  Figure  1-2,  the  UGV  Vx  Capability  Plan  document  identifies  specific 
capabilities  and  functionality  that  are  within  scope  of  the  current  Version  level  of  the  IOP 
effort.  These  requirements  flow  directly  or  indirectly  to  individual  lOPs  where  additional 
level  of  detail  is  derived  to  support  the  IOP  objective  These  are  then  further 
decomposed  within  the  JAUS  Profiling  Rules  document  to  define  specific  interface 
requirements  (e.g.,  synchronous  message  rates)  and  behavior  required  to  implement 
the  defined  Capability  Plan  requirement(s).  Requirements  from  all  of  these  levels,  in 
addition  to  requirements  cited  within  the  contract  performance  specification,  are  flowed 
to  the  conformance  and  test  activity  to  support  a  given  system/subsystem  test  and 
validation  activity.  For  each  individual  acquisition  program,  the  Project  Manager  (PM) 
representatives  will  review  the  IOP  package  and  select  which  Interoperability  Attribute 
values  will  apply,  based  on  system  requirements.  The  requirements  associated  with 
those  Interoperability  Attributes  will  then  become  part  of  the  contractual  requirements 
for  that  program. 


1.3.2  UGV  Classes  of  Vehicles 

The  UGV  IOP  is  targeted  toward  a  limited  set  of  UGV  classes.  These  class  definitions 
have  been  defined  by  the  Joint  Ground  Robotics  Integration  Team  (JGRIT).  In  the 
future,  the  JGRIT  plans  to  define  additional  categories  (e.g.,  small,  micro,  nano),  with 
each  category  having  multiple  variants  with  roles  defined  by  modular  mission  payloads 
mounted  on  a  common  platform.  The  current  classification  is  as  follows: 
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UGV  Class  of  Vehicles  (CoV).  Army  UGV  CoV  are  categorized  according  to 
transportability  within  the  four  following  classes: 

•  Warfighter  Transportable  CoV  is  the  UGV  class  small  enough  for  Warfighters 
to  carry  for  extended  periods.  Within  this  class  are  the  Single  Warfighter  and 
Crew  Served  Robotic  systems. 

•  Vehicle  Transportable  CoV  is  larger  than  Soldier  Transportable  CoV  and  must 
be  transported  by  another  system,  such  as  in  a  truck,  on  a  trailer,  or  towed  to  its 
mission  location. 

•  Self  Transportable  CoV  is  the  UGV  class  large  enough  to  transport  itself  and 
required  payloads  for  extended  periods. 

•  Applique  System  is  an  add-on  standard  robotics  conversion  applique  kit,  that 
will  enable  a  manned  vehicle  to  operated  unmanned  at  the  commander’s 
discretion.  The  applique  system  equipped  vehicle  is  a  scalable  UGV  with  controls 
from  manual  operation  to  fully  autonomous  while  maintaining  its  transportability 
as  an  unmanned  vehicle  the  same  as  it  did  as  a  manned  vehicle. 


Given  that  UGV  classes  will  impact  the  usage  and  application  of  the  UGV  IOP,  “UGV 
Class”  has  been  adopted  as  an  Interoperability  Attribute.  The  applicability  of  this 
attribute  will  be  defined  within  relevant  sections  of  the  UGV  IOP  as  it  is  employed. 
Currently  there  are  no  specific  requirements  for  any  one  CoV. 

1.3.3  Implementation  of  Standards 

The  UGV  IOP  defines  standards  as  well  as  guidance  with  respect  to  implementation  in 
order  to  promote  interoperability  as  required  by  the  acquisition  program  managers. 
Standards  requirements  are  identified  in  a  variety  of  areas,  including  electrical, 
mechanical,  video,  audio,  communications,  and  messaging.  However,  due  to  the  broad 
scope  and  expected  operational  usage  of  UGVs,  not  all  standards  will  be  applicable  to 
every  system. 

Acquisition  programs  requiring  conformance  to  this  IOP  will  specify  their  interoperability 
requirements  such  that  system  developers  can  identify  and  conform  to  the  applicable 
sections  of  the  IOP. 

System  developers  shall  adhere  to  the  standards  and  guidance  as  mandated  within 
their  procurement  contracts  relating  to  this  IOP.  Robotic  system  end  items  shall  be 
tested  and  validated  in  accordance  with  the  conformance  and  validation  clauses 
contained  within  this  overarching  profile,  as  well  as  those  contained  in  applicable 
companion  IOP  documents. 

1.3.4  Control  and  Status  Messages  &  JAUS  Profiling 

To  the  degree  possible,  the  UGV  IOP  utilizes  the  SAE  AS-4  JAUS  standards  to  define 
the  interfaces  between  the  OCU  and  the  UGV  as  well  as  among  on-board  UGV 
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subsystems.  The  UGV IOP  SAE  AS-4  JAUS  Profiling  Rules  document  provides 
guidance  with  respect  to  the  profiling  of  the  JAUS  standard,  in  order  to  define  the 
manner  in  which  interfaces  are  applied/interpreted  as  a  means  of  limiting  ambiguity  and 
maximizing  interoperability  among  disparate  vendors. 

1.3.5  Custom  Services,  Messages,  and  Transports 

A  set  of  “custom”  UGV  IOP  services  has  been  defined  to  provide  mission  capabilities 
scoped  within  the  UGV  IOP  domain  that  are  either  not  currently  available  in  the  SAE 
JAUS  standards  or  require  SAE  JAUS  extension  by  the  SAE  AS-4  Committee.  These 
messages  are  documented  in  the  UGV  IOP  Custom  Services,  Messages,  and 
Transports  document.  To  the  extent  possible,  Custom  Services,  Messages,  and 
Transports  will  be  avoided,  and  when  deemed  necessary  will  be  taken  to  the  SAE  JAUS 
committee  for  consideration  of  inclusion  in  a  future  public  release.  If/when  Custom 
Services,  Messages,  and  Transports  have  been  accepted  and  published  within  the 
applicable  SAE  AS-4  JAUS  standards,  they  will  be  removed  from  the  UGV  IOP  Custom 
Services,  Messages,  and  Transports  document. 

1.3.6  Latency 

Latency  requirements  govern  the  overall  system  performance  and  can  be  defined  at 
various  levels.  For  example,  the  control  of  a  UGV  manipulator  can  be  measured  from 
input  on  the  OCU  to  the  commanded  movement  of  the  manipulator  or  at  various  points 
along  the  thread  to  include  OCU  to  comms  link  transmission,  comms  link  transmission 
to  comms  link  reception,  comms  link  reception  to  manipulator.  In  general  latency  will  be 
a  factor  of  the  operational  mission/mission  parameters  and  will  not  necessarily  be 
applicable  to  every  UGV  system  in  the  same  regard.  For  this  reason,  latency 
requirements  will  be  identified  within  specific  Program  of  Record  (POR)  acquisition 
documentation.  The  ability  to  test  and  validate  latency  will  be  shown  through  a  set  of 
use  cases  as  defined  in  the  test  &  validation  documentation  developed  in  support  of  IOP 
VO  but  not  supplied  with  it. 
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2  Source  Documents 

The  following  documents  are  referenced  within  this  IOP  and  shall  be  used  to  implement 
the  requirements  contained  within  the  IOP. 


2. 1  Government  Documents 


1011-1-2.0 


NIST  Special  Publication,  Autonomy  Levels  for  Unmanned  Systems 
(ALFUS)  Framework  Volume  I:  Terminology,  Version  2.0,  October  2008. 


2.2  Non-Government  Documents 


AIR5665A 

SAE  Aerospace  Information  Report,  Architecture  Framework  for 

Unmanned  Systems  (AFUS),  April  2009. 

ARP  6012 

SAE  Aerospace  Recommended  Practice,  JAUS  Compliance  and 
Interoperability  Policy,  April  2009. 

AS5669A 

SAE  Aerospace  Standard,  JAUS/SDP  Transport  Specification,  February 
2009. 

AS5684 

SAE  Aerospace  Standard,  JAUS  Service  Interface  Definition  Language, 
December  2008. 

AS5710 

SAE  Aerospace  Standard,  JAUS  Core  Service  Set,  December  2008. 

AS6009 

SAE  Aerospace  Standard,  JAUS  Mobility  Service  Set,  April  2009. 

AS6057 

SAE  Aerospace  Standard  (draft  0.5a),  JAUS  Manipulator  Service  Set. 

AS6040 

SAE  Aerospace  Standard  (draft  0.3),  JAUS  HMI  Service  Set. 

AS6060 

SAE  Aerospace  Standard  (draft  0.9),  JAUS  Environment  Sensing  Service 
Set. 

IEEE  802.3-2008 

Standards  for  Ethernet  based  LANs 
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3  Architecture 

3.1  System  Context 

From  a  system  perspective,  the  UGV  IOP  is  defined  to  address  interoperability  at 
multiple  levels  within  varying  systems  configurations.  The  context  diagram,  presented 
in  Figure  3-1,  depicts  this  concept  by  showing  the  UGV  and  a  controller  interfacing  to 
external  UxV  and  external  command  &  control  (C2)/battle  command  systems.  This 
concept  can  be  instantiated  in  a  number  of  ways  from  a  basic  OCU/UGV  configuration 
to  more  complex  configurations  ( i.e.,  an  OCU  controlling  multiple  UGVs  with  UAV  feeds 
and/or  a  communication  relay/extension).  Interoperability  can  be  applied  to  various 
aspects  of  these  configurations  as  required  by  the  system  product  manager,  to  include: 

-  OCU/UxV(s)  -  radio/data  interfaces 

-  Intra-OCU  -  between  and  among  OCU  hardware  and  software  elements 

-  Intra-UGV  -  between  and  among  UGV  subsystems/payloads  and  platform 

-  OCU/UGV  to  External  C2  Systems  -  exchange  of  command  and  control, 
battlespace,  and  audio/video  information. 

For  the  purposes  of  IOP  VO,  only  the  circled  portion  of  this  architecture  is  within  scope. 
This  includes  the  hardware  and  software  interfaces  to  define  interoperability  and 
modularity  between  a  platform  and  a  single  OCU,  between  a  platform  and  its  payloads, 
and  between  a  radio  and  a  platform  or  OCU,  and  between  an  OCU  and  its  human 
operator. 
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IOP  System  Context 


External 

C2  System(s) 

UxV(s) 

-  Video 

-  Audio 

-  Data 


IOP  VO 


LOS  Control  of  Multiple  UGVs 


Figure  3-1  UGV  IOP  Context 


3.2  Reference  Architecture 

The  architecture  presented  in 
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1^— I  -  -  Video 

-  Integrated  Component  -  -Audio 

◄  - ►  -  Interface  - Data 

<  - ►  -  Potential  Interface  -  -  Power 

Figure  3-2  builds  upon  the  system  context  and  defines  key  integrated  elements  of  the 
UGV  and  OCU  along  with  internal  and  external  interfaces.  These  elements  are  defined 
in  this  IOP  in  a  generic  (abstract)  manner  and  may  be  realized  within  a  system  in  a 
variety  of  ways.  For  example,  although  all  UGVs  will  have  a  conceptual  platform 
controller  to  provide  platform  and  mobility  processing,  the  platform  controller  may  be 
realized  as  a  single  computer,  a  single  line  replaceable  unit  (LRU)  with  multiple 
computers  or  a  set  of  LRUs  with  distributed  processing  and  internal  interfaces.  The 
terms  defined  and  presented  in  the  architecture  diagram  are  defined  to  provide  a 
consistent  terminology  and  point  of  reference  for  utilization  throughout  this  IOP. 
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Figure  3-2  UGV  IOP  Reference  Architecture 

As  depicted  in  the  figure,  systems  within  the  reference  architecture  are  comprised  of 
integrated  elements,  interfaces,  and  potential  interfaces.  An  integrated  element  is  an 
element  that  will  exist  (at  least  conceptually)  within  the  specified  system;  an  interface 
defines  an  inter  or  intra  system  linkage  between  integrated  elements;  and  a  potential 
interface  is  an  interface  that  may  or  may  not  exist  depending  upon  the  required 
functionality  as  specified  by  a  system’s  Interoperability  Attributes. 

3.2.1  Operator  Control  Unity  (OCU) 

The  OCU  system  of  the  reference  architecture  provides  the  human  operator  a  capability 
to  issue  commands  to  and  receive  input  back  from  one  or  more  UGVs.  Specific  OCU- 
level  requirements  are  included  within  the  Control  IOP. 

The  Input  and  Output  Device  element(s)  are  generic  and  could  be  adapted  to  describe  a 
traditional  controller  implemented  with  joysticks,  keyboard,  mechanical  switches,  and  a 
display,  or  other  types  of  controllers  such  as  those  implemented  with  a  glove,  video 
game  controller,  monocle,  voice,  smart  phone,  or  tactile  belt. 
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3.2.2  Common  Communications  Link  (CCL) 

The  Common  Communications  Link  (CCL)  element  is  an  abstraction  of  the  networking 
and/or  point-to-point  communications  solution  required  for  command  and  control  of 
UGVs.  It  provides  the  OCU  with  the  ability  to  transmit  and  receive  data  to/from  a  UGV, 
external  C2  System,  and/or  another  UxV. 

While  it  is  not  within  the  scope  of  IOP  VO  to  define  all  CCL  requirements,  it  does 
represent  the  first  “core”  set  of  requirements  defining  necessary  interoperable  behaviors 
for  near-term  UGV  radios.  A  future  Version  of  the  IOP  will  include  full  definition  of  how 
the  CCL  must  operate  in  the  long  term. 

3.2.3  Unmanned  Ground  Vehicle  (UGV) 

The  UGV  system  of  the  reference  architecture  consists  of  a  Platform  Controller  element 
integrated  with  zero  or  more  Payload  elements,  and  interfaced  externally  to  an  OCU 
and/or  UxV  and  External  C2  Systems  via  a  CCL  element.  The  Platform  Controller 
element  is  conceptually  responsible  for  providing  platform  management  (e.g.,  system 
diagnostic  monitoring,  system  safety,  BIT/FIT)  and  mobility.  The  Platform  Controller 
element  receives  data  and  provides  status  through  the  CCL  element.  The  Payload 
element(s),  if  present,  may  be  communicated  with  external  consumers  via  an  external 
connection  through  the  CCL  or  may  be  integrated  directly  to  the  Platform  Controller 
element.  An  example  of  a  Payload  element  with  a  direct  connection  to  the  CCL  might 
be  an  SAE  AS-4  JAUS  compliant  payload  that  can  be  discovered  and  communicated  to 
directly  by  an  OCU.  An  example  of  a  Payload  element  with  a  connection  to  the  Platform 
Controller  element  might  be  a  payload  with  an  SAE  AS-4  JAUS  interface  resident  on  the 
Platform  Controller  where  commands  to  the  SAE  AS-4  JAUS  interface  are  translated  to 
the  payload  in  a  non-SAE  AS-4  JAUS  format.  In  addition,  an  SAE  AS-4  JAUS 
compliant  payload  capable  of  interfacing  directly  to  an  OCU  may  still  have  an  interface 
to  the  Platform  Controller  in  order  to  provide  subsystem  status  and  to  register  for 
platform  data  (e.g.,  navigation,  state/mode).  The  Power  element  provides  power  to  all 
UGV  integrated  components. 

3.2.4  External  Command  &  Control  (C2) 

While  outside  the  scope  of  IOP  VO,  the  External  C2  system  of  the  reference  architecture 
provides  for  the  interfacing  of  an  OCU  and/or  UGV  with  an  external  system,  such  as  a 
battle  command  system.  Sharing  of  payload  data  into  external  ground  or  air  based 
systems  or  networks  will  be  addressed  in  a  future  version  of  this  IOP.  . 

3.2.5  Other  Unmanned  Vehicles  (UxVs) 

While  also  outside  the  scope  of  IOP  VO,  the  UxV  system  of  the  reference  architecture 
provides  for  the  coordinated  interaction  of  a  UxV  system  with  the  OCU  and/or  UGV. 

UxV  in  this  context  represents  a  generic  unmanned  system  to  include  another  UGV,  a 
UAV,  or  an  unattended  sensor.  Interface  requirements  for  communicating  with  UxVs 
outside  of  the  ground  domain  with  be  addressed  in  a  future  version  of  this  IOP.. 


13 


Unclassified 


3.3  UGV  Logical  Architecture 

In  addition  to  the  reference  and  system  architecture,  the  UGV  IOP  applies  to  logical 
architectures  for  both  the  OCU  and  the  UGV,  specifying  the  general  hardware  and 
software  interfaces  relevant  to  interoperability  within  the  OCU  and  UGV  systems.  The 
term  logical  refers  to  the  fact  that  these  elements  may  be  implemented  in  varying 
physical  configurations  and  that  the  physical  configuration  is  not  specifically  relevant  to 

An 


Figure  3-3  Example  UGV  Logical  Architecture 

The  solid  elements  depicted  in  the  figure  represent  elements  that  are  always  present 
within  the  UGV  system.  The  dashed  elements  represent  potential  elements  that  may  be 
present  within  the  UGV  system.  Similarly  the  solid  lines  between  elements  represent 
defined  element  interfaces  while  dashed  lines  represent  potential  element  interfaces. 
Within  the  UGV  IOP,  potential  element/interface  requirements  are  subset  via 
Interoperability  Attributes  to  provide  for  the  specification  of  a  basic  UGV  configuration 
that  can  be  augmented  to  accommodate  specific  interoperability  requirements  related  to 
the  interface  with  external  system(s).  A  brief  description  of  the  controller  elements  is 
presented  in  the  following  paragraphs. 

OS  (Element)  -  The  OS  represents  the  controller  operating  system.  In  general, 
requirements  related  to  the  operating  system  will  not  be  addressed  within  this  IOP  and 
will  instead  be  defined  via  acquisition  requirements  or  design  decisions. 

OS  Interface  Services  (Potential  Element)  -  The  OS  interface  services  specify  inter¬ 
process  communication  (IPC)  mechanisms  required  to  implement  interoperability 
interfaces  between  software  (application)  elements.  This  could  be  an  interface  between 
the  controller  application  and  an  external  system(s),  the  controller  application  and  a 
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vendor  plug-in,  and/or  an  interface  utilized  by  the  JAUS  system  to  provide  an  underlying 
transport. 

A /V  Codec  (Potential  Element)  -  The  A/V  Codec  represents  the  element  within  the 
system  that  decodes/encodes  digital  audio  and  video  data  streams.  The  codec  formats 
required  within  the  system  will  largely  be  dependent  upon  the  requirements  associated 
with  specific  payloads  and/or  the  communications  data  link. 

JAUS/Private  Message  Interface  (Element)  -  The  JAUS/Private  message  interface 
represents  the  element  responsible  for  interfacing  with  the  application  to  encode, 
marshal,  transmit  and  receive,  unmarshal,  and  decode  JAUS  messages  between  the 
controller  and  the  robotic  system(s).  This  element  may  be  incorporated  with  or  separate 
from  the  application  software  component. 

UGV  Application  (Element)  -  The  UGV  application  specifies  the  element  responsible 
for  the  logical  execution  of  the  UGV  system.  In  general  requirements  related  to  the 
application  will  not  be  addressed  within  this  IOP  and  will  instead  be  defined  via 
acquisition  requirements  or  design  decisions 

Platform  Controller  (Element)  -  The  platform  controller  specifies  the  element 
responsible  for  hosting  and  execution  of  the  UGV  application.  This  element  may  be 
realized  in  a  variety  of  ways  from  a  small  micro-controller  up  to  a  multi-LRU 
configuration  in  accordance  with  the  platform  size  and  mission 
capabilities/requirement(s).  In  general  internal  requirements  related  to  the  platform 
controller  will  not  be  addressed  within  this  IOP  and  will  instead  be  defined  via 
acquisition  requirements  or  design  decisions.  External  and  interfacing  requirements 
associated  with  the  platform  controller  will  be  defined  and  presented  within  this  IOP. 

CCL  (Element)  -  The  CCL  represents  the  communications  data  link  between  the 
controller  and  the  robotic  system.  The  requirements  governing  this  interface  are 
specified  within  the  UGV  IOP  Communications  Profile. 

Payload(s)  (Potential  Element)  -  The  Payload  element  specifies  the  element 
responsible  for  conducting  mission  specific  functions/capabilities  alone  or  in  concert 
with  other  payloads  and/or  the  UGV  platform.  This  element  may  be  realized  in  a  variety 
of  ways  and  configurations  in  accordance  with  the  platform  size  and  mission 
capabilities/requirement(s).  Internal  requirements  related  payloads  will  not  be 
addressed  within  this  IOP  and  will  instead  be  defined  via  acquisition  requirements  or 
design  decisions.  Payload  interfaces  to/from  the  platform  (e.g.,  electrical,  mechanical), 
as  well  as  interfaces  between  the  payload  and  external  systems  (e.g.,  data  formats, 
message  protocols)  are  defined  within  the  UGV  IOP  Payload  Profile. 
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4  IOP  Usage  Guide 

4.1  Overview  of  IOP  Usage  Process 

This  set  of  lOPs  will  be  used  by  both  the  Project  Manager  (PM)  community  and  the 
vendor  community.  For  convenience,  individuals  within  the  Materiel  Developer  (the  PM) 
will  be  referred  to  as  “MATDEV”.  Private  industry  (or  academia)  developers  of  systems, 
payloads,  radios,  technologies,  or  systems  engineering/integration  expertise  will  be 
referred  to  as  “vendors”. 

For  a  given  UGV  acquisition  program,  the  process  begins  with  the  MATDEV  reviewing 
the  operational  requirements  as  articulated  by  the  User  community.  These  will  typically 
be  articulated  in  the  form  of  a  Capabilities  Development  Document  (CDD)  or 
Capabilities  Production  Document  (CPD),  and  written  by  a  Combat  Developer,  such  as 
the  Army’s  Training  &  Doctrine  Command  (TRADOC),  or  the  USMC’s  Marine  Corps 
Combat  Development  Command  (MCCDC). 

The  MATDEV  will  then  use  systems  engineering  processes  to  transform  these 
operational  requirements  into  performance  requirements.  During  this  process,  the 
MATDEV  will  conduct  a  formal  review  of  the  IOP  documentation  and  select  Values  for 
each  of  the  Interoperability  Attributes  defined  within  the  set  of  lOPs.  Each 
Interoperability  Attribute  Value  has  an  associated  requirement,  which  will  be  inserted 
into  the  PM’s  contractual  requirements  for  the  program’s  Request  for  Proposal  (RFP). 
Selection  of  the  appropriate  Value  of  a  given  Interoperability  Attribute  will  often  require 
the  MATDEV  to  conduct  formal  trade  studies  to  inform  the  decision.  There  are  also  a 
number  of  Mandatory  Interoperability  Attributes,  who’s  requirements  will  be  imposed  on 
all  systems.  These  Mandatory  Interoperability  Attributes  are  described  within  the  JAUS 
Profiling  Rules  IOP. 

The  vendors  within  the  competition  space  will  then  implement  the  requirements  that 
have  been  selected  based  on  the  Interoperability  Attributes,  in  accordance  with  the 
lOPs,  and  particularly  in  accordance  with  the  JAUS  Profiling  Rules  IOP  and  the  Custom 
Services,  Messages  &  Transports  document. 

An  example  of  this  process  would  be  that  the  MATDEV  receives  a  new  requirement  for 
a  system  that  has  Leader  /  Follower  capabilities,  as  well  as  requirements  for  sensing 
Chemical,  Biological,  Radiological,  Nuclear  (CBRN)  threats.  In  this  case,  the  MATDEV 
will  know  that  in  addition  to  specifying  the  Mandatory  Mobility  Interoperability  Attributes 
of  “Core  Mobility”,  “Drive  Timeout”,  and  “Safety  Requirements”,  they  will  also  know  that 
they  must  select,  at  a  minimum,  the  “Leader  Follower  (LF)”  Value  (likely  in  addition  to 
most  of  the  other  selectable  values).  Similarly,  the  MATDEV  will  also  know  that  in  must 
also  specify  the  CBRN  Sensor  Attribute  Option,  in  addition  to  other  common  payload 
requirements.  The  requirements  associated  with  each  of  these  Values  would  then 
become  requirements  imposed  on  the  vendor  to  be  compliant  with  the  performance 
and/or  product  specifications. 
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4.2  Applicability  of  IOP  to  Stakeholders 

For  the  MATDEV,  the  lOPs  will  be  used  as  part  of  the  requirements  decomposition  & 
allocation  process  prior  to  release  of  RFPs.  It  should  be  noted  that  the  interface 
requirements  in  the  lOPs  represent  a  “product  level  specification”,  as  opposed  to  the 
typical  “performance  level  specification”  that  PMs  are  typically  responsible  for.  This  has 
been  done  intentionally  in  order  to  provide  sustained  interoperability  and  modularity  of 
systems  throughout  their  full  lifecycles.  MATDEVs  will  build  program-specific 
interoperability  requirements  into  their  RFPs  prior  to  being  released,  based  on  this  IOP. 
For  the  MATDEV,  the  Overarching  IOP,  Payloads  IOP,  Communications  IOP,  and 
Control  IOP  are  of  primary  interest,  since  those  contain  definitions  of  the  Interoperability 
Attributes,  and  the  applicable  requirements  for  each  of  the  selected  Values. 

For  vendors  who  are  marketing  products,  this  IOP  should  be  used  as  a  guide  for  what  to 
expect  in  future  RFPs.  This  package  of  documents  describes  the  hardware  and 
software  interfaces  that  the  RS  JPO  would  like  to  see  in  products  that  vendors  may  be 
developing.  For  vendors  who  are  awarded  RFPs  in  future  programs,  these  documents 
represent  the  technical  requirements  that  will  be  imposed  to  promote  interoperability. 

For  industry,  the  JAUS  Profiling  Rules  document  is  of  primary  interest,  as  it  contains  the 
product  level  specifications  that  can  be  implemented  to  build  interoperable  systems. 


4.3  Usage  of  Overarching  IOP 

The  Overarching  IOP  will  be  used  by  the  MATDEV  and  industry  to  serve  as  a 
description  of  the  intent  of  the  full  IOP  package,  to  describe  its  usage,  to  define 
overarching  requirements  for  all  systems,  to  point  to  applicable  sections  in  the  other 
lOPs,  and  to  define  Interoperability  Attributes  that  may  be  selected  by  the  MATDEV  to 
impose  interoperability  requirements  into  acquisition  contracts. 


4.4  Usage  of  Communications  IOP 

The  Communications  IOP  will  be  used  by  the  MATDEV  and  industry  to  define 
communications  and  radio  related  requirements  for  a  CCL,  to  point  to  applicable 
sections  in  the  other  lOPs,  and  to  define  communications  related  Interoperability 
Attributes  that  may  be  selected  by  the  MATDEV  to  impose  interoperability  requirements 
into  acquisition  contracts. 


4.5  Usage  of  Payloads  IOP 
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The  Payloads  IOP  will  be  used  by  the  MATDEV  and  industry  to  define  payload  related 
requirements  for  both  payloads  themselves  and  UGV  platforms,  to  point  to  applicable 
sections  in  the  other  lOPs,  and  to  define  payload  related  Interoperability  Attributes  that 
may  be  selected  by  the  MATDEV  to  impose  interoperability  requirements  into 
acquisition  contracts. 


4.6  Usage  of  Control  IOP 

The  Control  IOP  will  be  used  by  the  MATDEV  and  industry  to  define  desired  common 
qualities  of  controllers.  It  is  acknowledged  that  there  are  a  variety  of  types  of  controllers 
that  make  sense  for  different  missions,  and  the  technology  related  to  controllers  is 
evolving  rapidly,  particularly  based  on  advancements  being  made  in  the  mobile/smart¬ 
phone  and  gaming  markets.  The  current  Control  IOP  VO  contains  desired  guidelines  for 
user  interfaces  for  conventional  controllers,  but  does  not  mandate  explicit  requirements. 
Controllers  must  be  capable  of  communicating  JAUS-based  messages  as  defined  in 
this  IOP  package,  and  must  interface  with  the  CCL  as  defined  in  the  Communications 
IOP.  The  primary  intent  of  the  Control  IOP  is  to  promote  an  interoperable  Human 
Machine  Interface  (HMI),  which  means  that  the  relationship  between  the  controller  and 
the  human  operator  must  be  modular  based  on  minimized  training  for  operation  among 
different  systems.  If  controllers  can  support  the  JAUS-based  messages  described  in  this 
IOP  package,  then  interoperable  messages  will  become  the  interface  between  the 
controller  and  the  UGV  platform. 

For  example,  if  a  controller  operator  presses  a  keypad  arrow  to  turn  right,  then  an 
interpretable  message  command  will  be  received  and  understood  by  the  UGV  platform. 
If  another  controller  utilizes  a  joystick  to  turn  right,  then  the  UGV  platform  should  receive 
an  identical  message  as  that  sent  from  the  first  controller.  Similarly,  user  input  to  turn 
right  on  a  smartphone  type  accelerometer  device,  a  speech-based  device,  a  motion- 
recognition  device,  or  other  innovative  controller  technology  should  all  result  in  an 
identical,  interpretable  JAUS-based  message  being  received  by  the  UGV  platform. 

4.7  Usage  of  JAUS  Profiling  Rules  IOP 

The  JAUS  Profiling  Rules  IOP  will  be  used  primarily  by  industry  as  implementation 
guidance  for  complying  with  the  requirements  defined  within  all  of  the  other  lOPs.  It 
provides  the  product-level  JAUS-based  message  implementation  guidance,  and 
reference  to  the  appropriate  SAE  AS-4  JAUS  documents.  Additionally,  the  JAUS 
Profiling  Rules  IOP  will  be  used  by  the  MATDEV  in  developing  System  Integration  Labs 
(SILs)  for  verifying  that  the  lOPs  achieve  the  desired  outcomes,  as  well  as  assessing 
the  compliance  of  vendor  products  to  the  lOPs. 

4.8  Usage  of  Custom  Services,  Messages  &  Transports 

The  Custom  Services,  Messages  &  Transports  document  will  be  used  to  define  JAUS- 
based  services  that  are  not  currently  defined  in  any  existing  SAE  AS-4  JAUS  approved 
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document.  Currently  in  VO  the  Custom  Services,  Messages  &  Transports  document 
contains  JAUS-based  guidance  for  the  following  Custom  Services:  Leader 
Management,  Leader  Follower  Driver,  Communicator,  Platform  Mode,  Health  Monitor, 
Health  Reporter,  Digital  Stream  Discovery,  and  Preset  Pose.  Currently  there  are  no 
defined  custom  messages  or  custom  transports  in  this  document. 

It  is  the  intent  of  the  RS  JPO  for  each  of  the  custom  services,  messages,  and  transports 
defined  in  this  package  to  be  recommended  for  adoption  by  the  SAE  AS-4  JAUS 
Committee,  and  published  in  an  approved  SAE  document.  Once  the  services, 
messages,  or  transports  are  approved  in  a  published  SAE  document,  this  IOP  package 
will  be  modified  to  reference  the  new  published  document  instead  of  the  Custom 
Services,  Messages  &  Transports  document  (and  they  will  be  removed  from  the  subject 
document  as  well). 

Additionally,  proprietary  services,  messages,  or  transport  protocols  will  not  be  accepted 
into  this  document. 


5  UGV  System  Requirements 

This  section  specifies  interoperability  requirements  for  the  UGV  to  include  the  robotic 
platform  and  payload  interface.  These  requirements  are  organized  in  accordance  with 
the  reference  architecture  specified  in  Section  3  and  are  further  derived  in  accordance 
with  a  taxonomy  based  upon  the  Architecture  Framework  for  Unmanned  Systems 
(AFUS),  defined  in  SAE  AIR5665A.  The  taxonomy  has  been  employed  to  identify 
composable  capabilities,  such  that  they  can  be  specified  via  Interoperability  Attributes  to 
define  robotic  system/controller  interoperability  performance  specifications,  to  be  used 
in  acquisition  contracts. 

The  UGV  IOP  Taxonomy  shown  in  Figure  5-1  depicts  the  AFUS  branches  and 
highlights  sections  of  the  AFUS  that  have  been  extended  or  are  currently  not  in  use.  In 
addition,  the  figure  depicts  the  section  of  the  UGV  IOP  that  addresses  the  requirements 
relevant  to  each  branch/capability. 
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Figure  5-1  IOP  Composability  Taxonomy 
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Figure  5-2  Payload  Integration  Techniques 

The  Custom  Payload  Integration  technique  presented  in  the  figure  depicts  the 
employment  of  custom  interfaces  to  access  and  interface  to  the  payload  subsystem. 
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This  technique  would  be  achieved  by  not  mandating  the  capabilities/requirements 
documented  within  this  section.  This  method  would  be  considered  non-compliant  with 
the  IOP.  The  IOP  Payload  Integration  technique  utilizes  the  mechanical  and  connector 
interfaces  defined  within  this  section  to  specify  the  manner  in  which  payload(s)  are 
integrated  to  the  UGV  platform.  The  Legacy  Payload  Integration  technique  is  a  hybrid 
of  the  previous  two,  providing  the  use  of  defined  IOP  interfaces  to  integrate  the  payload 
to  the  platform  via  a  wrapper  (translation  subsystem)  that  communicates  to  the  payload 
via  a  custom  or  legacy  interface. 

5.1.1  Platform  Mounting 

This  section  defines  requirements  associated  with  the  physical  mounting  of  payload(s) 
to  the  UGV  platform.  This  is  defined  in  the  UGV  IOP  Payloads  Profile. 

5.1.2  Connectors 

This  section  defines  requirements  associated  with  the  physical/electrical  connectors 
employed  to  integrate  subsystems  and  payload(s)  to  the  UGV  platform.  This  is  defined 
in  the  UGV  IOP  Payloads  Profile. 


5.2  Network  Implementation  Requirements 

This  section  specifies  requirements  associated  with  the  robotic  system  network  as  it 
pertains  to  both  on-board  and  external  networks.  Some  requirements  defined  within 
this  section  may  have  a  direct  mapping  to  capabilities  defined  within  the  UGV  IOP 
Communications  Profile,  but  be  described  at  a  higher  level.  For  example,  quality  of 
service  (QoS)/prioritization  standards  would  be  provided  within  this  section  of  the  IOP 
but  standards  that  provide  for  the  physical  realization  to  perform  QoS  would  be  defined 
within  the  communications  profile. 

5.2.1  On-Platform  Routing 

This  section  defines  requirements  associated  with  the  routing  of  data  on-board  the  UGV 
platform.  This  is  defined  in  the  UGV  IOP  Communications  Profile. 


5.2.2  Platform  Databus 

This  section  defines  the  databus  requirements  associated  with  the  interchange  of  data 
among  defined  IOP  elements  and  subsystems  integrated  on  the  UGV  platform.  Due  to 
the  fact  that  not  all  robotic  platforms  require  a  databus,  requirements  within  this  section 
of  the  IOP  are  subset  via  a  Platform  Databus  Interoperability  Attribute.  This 
Interoperability  Attribute  currently  has  the  values  of  Ethernet  and  None,  where  the  value 
“None”  is  used  to  indicate  that  a  platform  databus  is  not  required. 

[OVA  001]  Robotic  systems  (vehicles)  with  a  designated  “Ethernet”  Platform  Databus 
Interoperability  Attribute  shall  provide  an  on-board  Gigabit  Ethernet  databus  IAW  IEEE 
802.3-2008  for  the  integration  of  components  and  payload  subsystems. 
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5.2.3  Internet  Protocol 

This  section  defines  the  internet  protocol  (IP)  requirements  associated  with  the 
interchange  of  data  among  defined  IOP  elements  and  subsystems  integrated  on  the 
UGV  platform.  These  requirements  are  defined  in  the  UGV  IOP  Communications 
Profile  and  the  JAUS  Profiling  Rules  IOP. 


5.2.4  Quality  of  Service 

Quality  of  Service  (QOS)  requirements  are  not  within  the  scope  of  IOP  VO.  These  will  be 
handled  uniquely  by  each  individual  Acquisition  Program. 


5.2.5  Information  Assurance 

Information  assurance  requirements  are  defined  with  the  Communications  IOP. 

5.3  Power  Requirements 

This  section  specifies  requirements  associated  with  the  power  generation  and 
management  subsystems  provided  on  the  UGV  platform  and  is  targeted,  primarily, 
towards  the  integration  of  interoperable  subsystems  and  payload  devices. 

[OVA  002]  The  UGV  platform  shall  supply  power  to  all  base  configuration  payloads. 


This  is  defined  in  further  detail  in  the  UGV  IOP  Payloads  Profile.  Additionally,  each 
individual  Acquisition  Program  will  need  to  perform  an  analysis  to  determine  what  the 
base  configuration  is,  as  well  as  power  management  techniques  to  support  a  dynamic 
payload  configuration. 


5.4  Payload(s)  Requirements 

Requirements  governing  the  interfacing  with  mission  equipment  payloads  are  defined 
within  the  Payloads  Profile  portion  of  the  UGV  IOP. 

[OVA  003]  Payloads  shall  be  implemented  in  accordance  with  the  UGV  IOP  Payloads 
Profile  and  any  required  (specified)  Interoperability  Attributes. 

5.5  Communications  Requirements 

The  communications  interface  is  the  interface  between  the  robotic  platform  and  a 
controller.  The  communications  interface  is  realized  via  the  CCL  Communications 
Profile  and  is  responsible  for  the  transmission  and  receipt  of  digital  data  (to  include 
video  and  audio). 

[OVA  004]  UGV  platforms  shall  implement  the  communications  data  link  interface  in 
accordance  with  the  UGV  IOP  Communications  Profile  and  any  required  (specified) 
Interoperability  Attributes. 
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5.6  Platform  Controller  Requirements 

5.6.1  Implementation  of  SAE  JAUS  Message  Set 

SAE  AS-4  JAUS  messages  provide  the  means  for  robotic  controllers  to  connect  to  and 
control  robotic  systems  to  include  robotic  systems  payloads.  Conformant 
implementations  of  this  IOP  shall  utilize  the  SAE  AS-4  JAUS  message  set  as  specified 
within  these  IOP  documents  and  in  accordance  with  the  specified  profiling  rules. 

5.6. 1.1  Command,  Control,  and  Status  Messages 

Command,  control,  and  status  messages  specify  the  set  of  messages  used  to  control  a 
robotic  system  to  perform  a  mission  function.  These  messages  support  control  of  a 
single  robotic  system  from  one  controller  as  well  as  control  of  multiple  robotic  systems 
by  a  single  controller,  or  shared  control  of  a  single  robotic  system  by  multiple 
controllers.  This  section  provides  the  interoperability  messaging  requirements  relevant 
to  controllers,  robotic  systems,  and  robotic  system  payloads. 

[OVA  005]  Command,  control  and  status  messages  shall  be  implemented  using  the 
SAE  AS-4  JAUS  standards  as  profiled  by  the  UGV  IOP  SAE  JAUS  Profiling  Rules  and 
any  required  (specified)  Interoperability  Attributes. 

5.6. 1.2  Custom  Messages 

Custom  (or  “private)  messages  provide  a  mechanism  to  specify  necessary  command, 
control,  and  status  messages  that  have  not  been  defined  within  the  specified  SAE  AS-4 
JAUS  standards.  For  the  UGV  IOP,  all  private  messages  approved  for  use  are  defined 
within  the  UGV  IOP  Custom  Services,  Messages  and  Transports.  Custom  messages 
are  controlled  within  the  UGV  IOP  activity  and  it  is  the  intent  of  the  RS  JPO  to  seek 
standardization  of  these  private  messages  within  the  applicable  SAE  AS-4  JAUS 
committees  and  seek  wide  adoption  within  the  Army  robotic  ground  vehicle  community. 

The  UGV  IOP  will  specify  the  use  of  SAE  AS-4  JAUS  messages  to  achieve 
interoperability  and  only  employ  private  messages  when  no  JAUS  message  will  suffice. 

Custom  messages  will  be  published  and  distributed  to  the  stakeholder  community 
without  proprietary  markings. 

[OVA  006]  Custom  command,  control  and  status  messages  shall  be  implemented  in 
accordance  with  the  RS  JPO,  UGV  IOP  Custom  Services,  Messages  and  Transports. 

5.6. 1.3  Transport 

SAE  JAUS  AS5669A  specifies  software  defined  protocols  to  be  employed  in  the 
dissemination  of  JAUS  messages  between  robotic  systems  and  robotic  controllers.  The 
transport  protocol  delineates  the  formats  and  protocols  employed  for  the  transport  of 
messages  between  compliant  entities  for  all  supported  link-layer  protocols  and  media. 
There  are  currently  three  transports  specified  in  AS5669A:  JUDP  (JAUS  over  UDP), 
JTCP  (JAUS  over  TCP),  and  JSerial  (JAUS  over  Serial). 
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The  Transport  Interoperability  Attribute  provides  for  the  specification  of  a  transport  and 
includes  the  following  as  defined  below  (JUDP,  JTCP,  Custom).  This  attribute  may  be 
designated  as  a  set  of  values,  as  applicable  (e.g.,  a  controller  that  controls  multiple 
robotic  systems  utilizing  different  transports). 

Transport  control  and  status  messages  shall  be  implemented  in  accordance  with  the  RS 
JPO,  UGV 10 P  JAUS  Profiling  Rules. 


5.6.1. 3.1  JUDP 

[OVA  007]  Robotic  systems  (controllers  and/or  vehicles)  with  a  designated  “JUDP” 
Transport  Interoperability  Attribute  Value  shall  implement  the  transport  in  compliance 
with  the  JUDP  transport  specified  in  SAE  JAUS  AS5669A. 

5.6.1. 3.2  JTCP 

[OVA  008]  Robotic  systems  (controllers  and/or  vehicles)  with  a  designated  “JTCP” 
Transport  Interoperability  Attribute  Value  shall  implement  the  transport  in  compliance 
with  the  JTCP  transport  specified  in  SAE  JAUS  AS5669A. 

5. 6. 1.3. 3  Custom  Transports 

It  is  acknowledged  that  over  time,  custom  transports  may  be  developed  that  employ 
paradigms/technologies  suitable  for  specific  robotic  command  and  control  environments 
(e.g.,  Service  Oriented  Architecture  and  Deterministic  Real  Time).  The  custom 
transport  specification  is  similar  in  concept  to  custom  messages,  in  that  it  is  an  agreed 
upon,  defined  transport  that  is  intended  to  fill  a  gap  while  undergoing  standardization 
within  the  SAE  AS-4  JAUS  community. 

Private  transports  will  be  pluggable  with  SAE  JAUS  AS5669A  transports  to  the  degree 
possible. 

[OVA  009]  Robotic  systems  (controllers  and/or  vehicles)  with  a  designated  “Custom” 
Transport  Interoperability  Attribute  Value  shall  implement  the  transport  in  compliance 
with  the  designated  Custom  transport  specified  in  UGV  IOP  Custom  Services, 
Messages  and  Transports. 

5.6.2  Platform  Management 

Capabilities  defined  within  this  section  map  to  the  platform/vehicle  capabilities  defined 
within  the  IOP  composability  taxonomy  (Figure  5-1 ).  For  Version  0  of  the  IOP,  the 
platform/vehicle  branch  has  been  subdivided  into  Basic  and  Advanced  platform 
management  capabilities.  Basic  platform  management  capabilities  encompass  the  set 
of  capabilities  that  are  generally  common  to  all  robotic  platforms,  while  advanced 
platform  management  capabilities  typically  relate  to  those  capabilities  that  are  found  in 
advanced  or  larger  UGV  platforms  (e.g.,  power  management,  fault  isolation,  autonomy). 
This  section  has  been  defined  and  subdivided  in  this  manner  to  demonstrate  the 
concept  of  defining  capabilities,  such  that  they  can  be  specified  for  incorporation  into  a 
robotic  system  end  item.  It  is  envisioned  that  in  future  revisions  of  this  IOP,  these 
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platform  management  capabilities  will  be  expanded  and  further  subdivided  to  provide 
necessary  levels  of  granularity  to  support  the  set  of  systems  within  the  UGV  IOP 
domain. 

This  IOP  defines  a  set  of  platform  management  modes  for  the  purposes  of  providing  a 
shared  context  among  controllers  and  robotic  systems  and  among  robotic  systems  and 
integrated  payloads  that  require  a  platform  state/mode  awareness  for  synchronization 
and  use.  Platform  modes  are  defined  to  be  extensible  in  order  that  they  can 
amended/extended  in  future  revisions  of  this  IOP.  The  platform  mode  state  diagram  is 
illustrated  below  in  Figure  5-3. 


System  Off 

Figure  5-3  Platform  Mode 


The  following  paragraphs  provide  a  brief  description  of  the  platform  modes  along  with 
an  indication  as  to  whether  or  not  the  mode  is  defined  within  the  basic  or  advanced 
platform/vehicle  capability.  Platform  modes  are  incorporated  into  the  platform 
management  capability  in  accordance  with  the  Platform  Management  Interoperability 
Attribute  (defined  below). 

Startup  (Basic  Mode)  -  the  startup  platform  mode  is  entered  upon  vehicle  power  on. 
The  platform  will  transition  from  startup  to  operational  mode  when  it  has  been 
determined  that  the  system  startup  is  ok  and  the  system  is  operational.  The  specific 
meaning  of  “startup  ok”  is  left  to  the  implementer  or  further  definition  of  acquisition 
requirements,  but  the  general  intent  is  that  the  system  and  its  on-board  subsystems  are 
available  for  use. 

Operational  (Basic  Mode)  -  the  operational  platform  mode  is  entered  upon  successful 
startup.  Once  the  system  has  achieved  the  operational  mode,  it  will  be  available  for  use 
by  a  controller. 
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Shutdown  (Basic  Mode)  -  the  shutdown  mode  is  entered  upon  operator  selection  from 
the  operational  mode.  Once  the  system  has  successfully  transitioned  into  shutdown 
mode,  it  will  gracefully  shutdown  on-board  subsystems  and  transition  to  a  power  off 
state. 

Combat  (Advanced  Mode)  -  While  not  within  scope  of  IOP  VO,  the  combat  platform 
mode  is  entered  upon  operator  selection  from  the  operational  or  training  mode.  The 
specific  requirements  associated  with  combat  mode  are  left  to  the  implementer  or 
further  definition  of  acquisition  requirements,  but  the  general  intent  is  that  combat 
systems  integrated  onto  the  platform  will  be  available  for  operator  selection,  arming,  and 
use  from  within  this  mode. 

Training  (Advanced  Mode)  -  While  not  within  scope  of  IOP  VO,  the  training  platform 
mode  is  entered  upon  operator  selection  from  the  operational  mode.  The  specific 
requirements  associated  with  training  mode  are  left  to  the  implementer  or  further 
definition  of  acquisition  requirements,  but  the  general  intent  is  that  the  platform  will  be 
placed  into  a  mode  to  support  instructional  training  of  operators  (e.g.,  inhibit  of 
platform/payload  response  to  commanded  action  and  potential  emulation  or  simulation 
of  platform/payload  output/status). 

Maintenance  (Advanced  Mode)  -  While  not  within  scope  of  IOP  VO,  the  maintenance 
platform  mode  is  entered  upon  operator  selection  from  the  operational  mode.  The 
specific  requirements  associated  with  maintenance  mode  are  left  to  the  implementer  or 
further  definition  of  acquisition  requirements,  but  the  general  intent  is  that  the  platform 
will  be  placed  into  a  mode  to  support  the  analysis  or  update  of  the  system  (e.g., 
reprogramming,  detailed  fault  analysis,  boresight).  As  with  training  mode,  it  is 
anticipated  that  certain  operational  aspects  of  the  system  would  be  inhibited  while  in 
maintenance  mode. 

Anti-Tamper  (Advanced  Mode)  -  While  not  within  scope  of  IOP  VO,  the  anti-tamper 
platform  mode  is  entered  upon  operator  selection  from  the  operational  mode.  The 
specific  requirements  associated  with  anti-tamper  mode  are  left  to  the  implementer  or 
further  definition  of  acquisition  requirements,  but  the  general  intent  is  that  the  platform 
will  be  placed  into  a  mode  where  it  initiates  a  self  awareness  of  threats  entering  defined 
zone(s)  and  initiates  defined  (potentially  progressive)  action(s)  against  detected  threats 
which  may  include  operator  authorization. 

Render  Useless  (Advanced  Mode)  -  While  not  within  scope  of  IOP  VO,  the  render 
useless  platform  mode  is  entered  upon  operator  selection  from  the  operational  mode. 
The  specific  requirements  associated  with  render  useless  mode  are  left  to  the 
implementer  or  further  definition  of  acquisition  requirements,  but  the  general  intent  is 
that  the  platform  will  be  placed  into  a  state  where  it  can  no  longer  be  operated  and  all 
on-board  data  will  be  destroyed. 

Timed  Shutdown  (Advanced  Mode)  -  While  not  within  scope  of  IOP  VO,  the  timed 
shutdown  mode  is  entered  upon  operator  selection  from  the  operational  mode.  This 
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mode  is  identical  to  the  shutdown  mode  with  the  additional  requirement  to  wait  a 
specified  amount  of  time  for  on-board  subsystems  and  processes  to  perform  a  graceful 
shutdown.  Specifying  a  timed  shutdown  with  a  time  of  zero  would  indicate  an 
immediate  shutdown  of  the  platform. 

The  Platform  Management  Interoperability  Attribute  provides  for  the  specification  of  a 
defined  set  of  components/services  that  can  be  used  as  the  basis  of  a  contract  between 
a  controller  and  a  vehicle;  i.e.,  a  controller  that  supports  these  option(s),  will  know  what 
to  expect  and  how  to  control  a  vehicle  that  implements  the  same  option(s).  The 
Platform  Management  Interoperability  Attribute  Values  that  can  be  selected  are  None, 
Basic,  or  Advanced;  where  the  specified  value  relates  to  the  capability  to  be 
implemented.  These  capabilities  are  further  described  in  the  following  subsections. 

5.6.2. 1  None 

A  Platform  Management  Interoperability  Attribute  Value  of  “None”  indicates  that 
platform/vehicle  capability  is  provided  in  a  user  defined  manner  in  accordance  with  the 
services  defined  in  the  JAUS  specifications  and  that  the  platform/vehicle  capabilities 
defined  herein  do  not  apply. 

[OVA  010]  Robotic  systems  (controllers  and/or  vehicles)  with  a  Platform  Management 
Interoperability  Attribute  Value  of  “None”  shall  do  so  in  accordance  with  the 
requirements  specified  in  the  UGV IOP  SAE  JAUS  Profiling  Rules. 

5.6.2.2  Basic 

A  Platform  Management  Interoperability  Attribute  Value  of  “Basic”  provides  general 
platform  control/status  information  to/from  the  robotic  system  to  include  battery  status, 
platform  gauges,  position/attitude,  preset  pose,  subsystem  configuration,  subsystem 
enable/disable,  usage,  and  vehicle/subsystem  health.  In  addition,  the  basic  capability 
provides  for  the  definition  of  a  platform  mode  with  a  limited  set  of  mode  options  (startup, 
shutdown,  timed,  shutdown,  and  operational). 

[OVA  011]  Robotic  systems  (controllers  and/or  vehicles)  implementing  the  “Basic” 
Platform  Management  Interoperability  Attribute  shall  do  so  by  implementing  the  Platform 
Manager  JAUS  Node  in  accordance  with  the  Basic  Platform  Management  requirements 
specified  in  Section  4.2.1 .1  of  the  UGV  IOP  SAE  JAUS  Profiling  Rules. 

5.6.2. 3  Advanced 

A  Platform  Management  Interoperability  Attribute  Value  of  “Advanced”  includes  all  of  the 
basic  platform  capabilities  and  adds  additional  platform  modes  of  operation 
(maintenance,  render  useless,  anti-tamper,  combat,  and  training),  built  in  test  (BIT), 
fault  isolation  and  test  (FIT),  platform  articulation  (poses),  calibration,  and  software 
update. 

[OVA  012]  Robotic  systems  (controllers  and/or  vehicles)  implementing  “Advanced” 
Platform  Management  Interoperability  Attribute  shall  do  so  by  implementing  the  Platform 
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Manager  JAUS  Node  in  accordance  with  the  Advanced  Platform  Management 
requirements  specified  in  the  UGV IOP  SAE  JAUS  Profiling  Rules. 

5.6.3  Mobility 

Mobility  capabilities  provide  for  the  mobilization  of  the  platform  in  support  of  mission 
objectives  (the  manner  in  which  a  robotic  system  moves  from  place  to  place,  under  its 
own  power  and  under  any  mode  or  method  of  control  [ALFUS]).  The  mobility  capability 
is  subdivided  into  composable  sets  of  capabilities  commensurate  with  typical  modes  of 
operation  found  in  robotic  systems  across  the  UGV  IOP  domain.  These  capabilities  are 
organized  in  a  simple  level  of  autonomy  hierarchy  and  are  not  necessarily  mutually 
exclusive  (i.e.,  some  may  be  prerequisites  to  others).  For  example,  Advanced 
Navigation  presumes  Basic  Navigation  and  Teleoperation  presumes  Remote  Control. 
Mobility  has  been  subdivided  in  this  manner  to  support  increasing  levels  of  complexity 
from  UGVs  controlled  in  view  of  the  operator  to  UGVs  capable  of  processing  and 
executing  complex  mission  plans  supporting  reconnaissance,  patrol,  security,  and  other 
operations.  Mobility  JAUS  services  will  be  made  available  from  within  the  platform 
operational,  combat,  and  training  modes;  where  required,  and  are  implemented  via 
JAUS  services  specified  within  the  SAE  JAUS  Profiling  Rules. 


The  Mobility  Interoperability  Attribute  provides  for  the  specification  of  a  defined  set  of 
elements/services  that  can  be  used  as  the  basis  of  a  contract  between  a  controller  and 
a  vehicle  with  respect  to  mobility  modes  of  operation  (a  controller  that  supports  these 
options  will  know  what  to  expect  and  how  to  control  a  vehicle  that  implements  the  same 
options).  For  IOP  VO,  the  Mobility  Interoperability  Attribute  can  be  selected  as  Values  of 
Remote  Control,  Teleoperation,  or  Basic  Navigation.  Advanced  Navigation  will  be  added 
to  the  scope  in  future  versions  of  the  IOP.  It  is  envisioned  that  these  mobility  capabilities 
will  be  further  subset  in  future  revisions  to  support  requirements  in  relation  to  specific 
mission  objectives. 

5.6. 3.1  Remote  Control 

The  Value  “Remote  Control”  of  the  Mobility  Interoperability  Attribute  denotes  a  mobility 
capability  (mode  of  operation)  wherein  the  human  operator  controls  the  robotic  system 
on  a  continuous  basis,  from  a  location  off  the  robotic  system  via  only  her/his  direct 
observation.  In  this  mode,  the  robotic  system  takes  no  initiative  and  relies  on 
continuous  or  nearly  continuous 
input  from  the  human  operator  [ALFUS]. 

[OVA  013]  Robotic  systems  (controllers  and/or  vehicles)  implementing  the  “Remote 
Control”  Value  of  the  Mobility  Interoperability  Attribute  shall  do  so  by  implementing  the 
appropriate  JAUS  services  in  accordance  with  the  definition  and  rules  specified  in 
Section  4.3.4  of  the  UGV  IOP  SAE  JAUS  Profiling  Rules. 

5.6. 3.2  Teleoperation 

The  Value  “Teleoperation”  of  the  Mobility  Interoperability  Attribute  denotes  a  mobility 
capability  (mode  of  operation)  wherein  the  human  operator,  using  sensory  feedback, 
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either  directly  controls  the  actuators  or  assigns  incremental  goals  on  a  continuous  basis, 
from  a  location  off  the  robotic  system  [ALFUS]. 

[OVA  014]  Robotic  systems  (controllers  and/or  vehicles)  implementing  the 
“Teleoperation”  Value  of  the  Mobility  Interoperability  Attribute  shall  do  so  by 
implementing  the  appropriate  JAUS  services  in  accordance  with  the  definition  and  rules 
specified  in  Section  4.3.5  of  the  UGV IOP  SAE  JAUS  Profiling  Rules. 

5.6. 3. 3  Basic  Navigation 

The  Value  “Basic  Navigation”  of  the  Mobility  Interoperability  Attribute  defines  a 
capability  commensurate  with  robotic  systems  that  provide  simple  autonomy  via  the 
definition  of  simple  waypoint  following  or  leader  following  plans.  The  manner  in  which 
the  navigation  is  accomplished  is  not  configurable  (is  not  typically  affected)  by  the 
operator/controller  system.  The  Basic  Navigation  capabilities  that  are  within  the  scope 
of  IOP  VO  are  waypoint  following  and  leader/follower.  While  waypoint  following 
interoperability  is  achieved  through  the  existing  AS6009  JAUS  Mobility  Service  Set,  a 
new  service  for  leader/follower  has  been  defined  in  the  Custom  Services,  Messages  & 
Transports  document. 

[OVA  015]  Robotic  systems  (controllers  and/or  vehicles)  implementing  the  “Basic 
Navigation”  Value  of  the  Mobility  Interoperability  Attribute  shall  do  in  accordance  with 
Section  4.3.6  of  the  UGV  IOP  SAE  JAUS  Profiling  Rules. 


5.6. 3.4  Advanced  Navigation 

While  not  within  the  scope  of  IOP  VO,  the  future  Mobility  Interoperability  Attribute  of 
“Advanced  Navigation”  will  define  a  capability  commensurate  with  robotic  systems  that 
provide  advanced  autonomous  navigation  above  and  beyond  basic  navigation. 
Additional  capabilities  include  the  ability  to  specify  planner(s),  contingencies, 
coordination  data  in  support  of  robot  teaming,  detection  and  reporting  of  obstacle  data, 
and  the  ability  to  load/query/report  geospatial  data  in  a  variety  of  formats. 

5.6.4  Identification 

Identification  provides  for  the  discovery  and  comprehension  in  relation  to  one  or  more 
robotic  systems,  to  include  subsystems,  and  their  associated  capabilities.  Capabilities 
pertaining  to  identification  are  provided  in  accordance  with  SAE  AS-4  JAUS  core 
services,  primarily  discovery.  Requirements  related  to  the  implementation  of  the  JAUS 
core  service  set  are  defined  within  the  UGV  IOP  SAE  JAUS  Profiling  Rules. 

5.6.5  Authority 

Authority  provides  for  the  access  and  access  control  associated  with  a  robotic  system, 
to  include  its  integrated  subsystems.  Capabilities  pertaining  to  authority  are  provided  in 
accordance  with  SAE  AS-4  JAUS  core  services,  primarily  access  control. 
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Requirements  related  to  the  implementation  of  the  JAUS  core  service  set  are  defined 
within  the  UGV IOP  SAE  JAUS  Profiling  Rules. 

5.7  Safety,  Environmental,  and  Other  Requirements 

While  safety,  environmental,  and  other  requirements  are  important  to  any  system, 
requirements  for  those  areas  will  not  be  defined  by  this  IOP.  However,  consideration  of 
the  impact  on  these  areas  was  taken  into  account  in  the  selection  of  the  appropriate 
IOP  requirements  contained  through  the  set  of  IOP  documents. 
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6  Controller  Requirements 

Controller  or  Operator  Control  Unit  (OCU)  requirements  define  the  set  of  capabilities 
necessary  to  interface  to,  control,  and  maintain  the  status  of  an  unmanned  system(s). 
This  includes  not  only  the  functional  capabilities  to  be  effected  by  the  controller  but  also 
the  message  protocol  and  transport  requirements.  Within  the  UGV  IOP,  controller 
capabilities  are  specifically  addressed  and  defined  within  the  UGV  IOP  Control  Profile. 

[OVA  016]  Controller  requirements  shall  be  implemented  in  accordance  with  the  UGV 
IOP  Control  Profile. 
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7  Interoperability  Attributes 

The  following  table  specifies  the  set  of  Interoperability  Attributes  defined  within  this  IOP. 
These  attributes  are  used  to  specify  required  interoperable  capabilities  to  be 
implemented  within  a  robotic  system  controller.  The  specification  of  an  Interoperability 
Attribute  may  imply  additional  requirements  defined  in  other  portions  of  the  IOP. 


Attribute 

Paragraph 

Title 

Values 

UGV  Class 

1.3.2 

UGV  Classes 

Soldier  Transportable, 
Vehicle  Transportable, 

Self  Transportable, 
Applique  Package 

Platform  Databus 

5.2.2 

Databus 

None,  Ethernet 

Transport 

5.6. 1.3 

Transport 

UDP,  TCP,  Custom 

Platform 

Management 

5.6.2 

Platform  Management  & 
Platform  Modes 

None,  Basic,  Advanced 

Mobility 

5.6.3 

Mobility 

Remote  Control, 
Teleoperation,  Basic 
Navigation 
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8  Conformance  and  Validation  Requirements 

The  table  below  specifies  the  conformance  requirements  associated  with  this  IOP.  This 
matrix  maps  product  unique  identifiers  (PUIs)  to  applicable  IOP  requirements, 
paragraph  numbers,  titles/subtitles,  and  planned  verification  methods.  System 
Developers,  Conformance  and  Verification  Testers,  and  Acquisition  Managers  can  use 
this  matrix  to  help  validate  conformant  implementations  to  this  IOP.  The  following 
verification  methods  are  defined: 

Analysis  -  Analysis  is  an  element  of  verification  that  uses  established  technical  or 
mathematical  models  or  simulations,  algorithms,  charts,  graphs,  circuit  diagrams,  or 
other  scientific  principles  and  procedures  to  provide  evidence  that  stated  requirements 
were  met. 

Examination  -  Examination  is  an  element  of  verification  that  is  generally 
nondestructive  and  typically  includes  the  use  of  sight,  hearing,  smell,  touch,  and  taste; 
simple  physical  manipulation;  and  mechanical  and  electrical  gauging  and  measurement. 

Demonstration  -  Demonstration  is  an  element  of  verification  that  involves  the  actual 
operation  of  an  item  to  provide  evidence  that  the  required  functions  were  accomplished 
under  specific  scenarios.  The  items  may  be  instrumented  and  performance  monitored. 

Test  -  Test  is  an  element  of  verification  in  which  scientific  principles  and  procedures  are 
applied  to  determine  the  properties  or  functional  capabilities  of  items. 


PI  II 

Paragraph 

(U) 

Titla 

Verification  Method 

“Ul 

i  me 

A 

E 

D 

T 

N/A 

001 

5.2.2 

u 

Platform  Databus 

E 

002 

5.3 

u 

Power  Requirements 

D 

003 

5.4 

u 

Payloads  Requirements 

D 

004 

5.5 

u 

Communications  Requirements 

D 

005 

5.6.1. 1 

u 

Command,  Control  and  Status 

Messages 

D 

006 

5.6.1 .2 

u 

Custom  Messages 

D 

007 

5.6.1 .3.1 

u 

JUDP 

D 

008 

5.6.1 .3.2 

u 

JTCP 

D 

009 

5.6.1 .3.3 

u 

Custom  Transports 

D 

010 

5.6.2. 1 

u 

Platform  Management  (None) 

D 

011 

5.6. 2. 2 

u 

Platform  Management  (Basic) 

D 

012 

5.6. 2. 3 

u 

Platform  Management  (Advanced) 

D 

013 

5.6.3. 1 

u 

Mobility  -  Remote  Control 

D 

014 

5.6. 3. 2 

u 

Mobility  -  Teleoperation 

D 

015 

5.6. 3. 3 

u 

Mobility  -  Basic  Navigation 

D 

016 

6.0 

u 

Controller  Requirements 

D 
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9  Appendix  A  -  Acronyms  and  Abbreviations 


AEODRS 

AFUS 

ALFUS 

BIT 

CCL 

DISR 

DoD 

FIT 

IA 

IP 

JAUS 

JGRIT 

LRU 

OCU 

QoS 

SA 

SAE 

SWB 

TCP 

UAS 

UDP 

UGV 

UxV 


Advanced  Explosive  Ordnance  Disposal  Robotic  System 
Architecture  for  Unmanned  Systems 
Architecture  Levels  for  Unmanned  Systems 
Built  in  Test 

Common  Communications  Link 

DoD  Information  Technology  Standards  Registry 

Department  of  Defense 

Fault  Isolation  and  Test 

Information  Assurance 

Internet  Protocol 

Joint  Architecture  for  Unmanned  Systems 

Joint  Ground  Robotics  Integration  Team 

Line  Replaceable  Unit 

Operator  Control  Unit 

Quality  of  Service 

Situational  Awareness 

Society  of  Automotive  Engineers 

Software  Blocking 

Transmission  Control  Protocol 

Army  Unmanned  Aircraft  Systems 

User  Datagram  Protocol 

Unmanned  Ground  Vehicle 

Unmanned  Vehicle 
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10  Appendix  B  -  Definitions 


Actuator:  An  actuator  is  a  mechanical  device  that  can  change  shape  in  response  to  a 
signal.  An  actuator  can  be  a  simple  device  that  has  linear  movement  (prismatic)  or 
rotational  movement  (revolute),  or  it  can  be  an  articulated  manipulator  arm  with  many 
joints  and  links.  The  classic  manipulator  is  an  "arm"  of  a  robotic  system  used  to  position 
an  end-effector.  Another  common  manipulator  is  a  pan-tilt  unit  often  used  to  position  a 
directional  sensor  or  emitter.  At  this  time,  all  unpowered  devices  attached  to  a  robot  will 
also  be  classified  as  an  actuator.  (Examples  include  rakes,  extensions,  and  bumpers.) 

Analysis:  Analysis  is  an  element  of  verification  that  uses  established  technical  or 
mathematical  models  or  simulations,  algorithms,  charts,  graphs,  circuit  diagrams,  or 
other  scientific  principles  and  procedures  to  provide  evidence  that  stated  requirements 
were  met. 

Capability:  A  capability  is  a  single  operationally  relevant  function  -  for  example, 
teleoperation  would  be  a  capability  that  provides  the  function  of  allowing  a  user  to  drive 
a  vehicle  non-line  of  sight  using  a  camera. 

Complex  Payload:  A  complex  payload  is  a  payload  that  aggregates  multiple 
capabilities  either  logically  or  physically.  A  complex  payload  shall  always  be 
represented  by  a  JAUS  node. 

Demonstration:  Demonstration  is  an  element  of  verification  that  involves  the  actual 
operation  of  an  item  to  provide  evidence  that  the  required  functions  were  accomplished 
under  specific  scenarios.  The  items  may  be  instrumented  and  performance  monitored. 

Emitter:  An  emitter  is  a  device  that  can  discharge  a  substance  or  energy  into  the 
environment.  Examples  include  radio,  RADAR,  LASER,  loudspeaker,  liquid  jet  or 
disruptor  or  sprayer,  ballistic  weapons,  and  launchers  for  various  self-propelled  devices. 
An  emitter  can  be  a  hardware  device  that  generates  some  form  of  oscillating 
electromagnetic  fields,  which  is  intended  to  convey  information  (via  modulation)  to  a 
receiver  (i.e.  radios).  An  emitter  can  be  a  device  that  creates  acoustic  pressure  waves 
to  convey  audible  information,  or  to  incapacitate  those  in  hearing  range  with  very  high 
energy  acoustic  waves.  An  emitter  can  also  be  a  device  that  discharges  a  solid  object 
on  a  ballistic  trajectory;  drops  objects  by  way  of  gravity  (special  case  of  ballistics); 
shoots  a  jet  or  water  or  other  liquid,  a  disruptor;  etc.  Most  weapons  fall  into  the  class  of 
emitters. 

Examination:  Examination  is  an  element  of  verification  that  is  generally  nondestructive 
and  typically  includes  the  use  of  sight,  hearing,  smell,  touch,  and  taste;  simple  physical 
manipulation;  and  mechanical  and  electrical  gauging  and  measurement. 

Interoperability  Attribute:  This  concept  is  defined  in  Section  1.3.1. 
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JAUS  Component:  A  JAUS  component  is  a  logical  grouping  of  services.  Each  JAUS 
component  aggregates  services  to  provide  a  single  operationally  relevant  capability. 

The  JAUS  component  offers  a  service  interface  to  other  consuming  components  to  use. 
For  example,  teleoperation  could  be  a  JAUS  component  that  aggregates  a  primitive 
driver  service  and  some  sensor  services  to  provide  teleoperation  capabilities  to  a 
robotic  controller. 

JAUS  Node:  JAUS  nodes  are  a  logical  grouping  of  JAUS  components  within  a  JAUS 
subsystem.  Within  this  IOP,  JAUS  nodes  are  specified  to  aggregate  related 
capabilities.  This  aggregation  may  be  either  logical  (i.e.  any  capability  that  affects 
platform  motion  is  aggregated  under  the  Mobility  JAUS  node)  or  physical  (i.e.  a 
manipulator  payload  with  two  cameras  and  a  sensor  on  it  are  considered  a  JAUS  node). 

JAUS  Service:  JAUS  services  represent  the  lowest  level  of  the  JAUS  topology.  For  the 
purposes  of  this  IOP,  JAUS  services  provide  an  abstraction  to  hardware  or  software 
algorithms  that  reside  on  the  platform.  JAUS  services  may  by  internalized  within  a 
JAUS  component  or  may  be  provided  via  an  interface  that  is  consumed  by  other  JAUS 
components. 

JAUS  Subsystem  :  A  JAUS  subsystem  is  an  independent  and  distinct  unit  within  a 
JAUS  system.  JAUS  subsystems  include  robotic  controllers,  robotic  platforms,  and 
video  terminals  connected  and  communicating  via  a  specified  set  of  Interoperability 
Attributes.  A  JAUS  subsystem  contains  one  or  more  JAUS  nodes. 

JAUS  System:  The  top  level  element  within  the  JAUS  topology  and  can  encompass  all 
interoperable  elements  (robotic  controllers  and  robotic  platforms).  The  JAUS  system 
contains  multiple  JAUS  subsystems. 

Payload:  A  robot  payload  is  a  physical  device  that  interfaces  to  the  robot  using 
interoperable  physical,  power,  and  /  or  data  interfaces,  and  is  replaceable  (modular) 
based  on  mission  needs.  A  payload  can  be  similar  in  nature  to  other  devices  that  are 
integrated  on  a  robotic  vehicle,  but  a  payload  is  not  required  for  native  UGV  capabilities. 

Sensor:  Sensors  codify  information  from  the  environment  and  can  be  used  to  reason 
about  the  environment.  Typical  sensor  types  include,  but  are  not  limited  to,  tactile, 
proprioceptive,  seismic,  acoustic,  meteorological,  chemical,  biological,  radiological, 
nuclear,  visual,  and  range  finding.  All  sensors  fall  into  two  categories,  either  passive  or 
active.  Passive  sensors  perform  their  detection  without  effecting  or  altering  the 
environment  (i.e.  thermometer).  Active  sensors  use  some  form  of  emission  to  detect 
the  reflection  or  other  effect  that  emission  has  on  the  environment  (i.e.  radar). 

Test:  Test  is  an  element  of  verification  in  which  scientific  principles  and  procedures  are 
applied  to  determine  the  properties  or  functional  capabilities  of  items. 
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